home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970104-19970326 / 000402_news@columbia.edu _Tue Mar 11 14:22:05 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id OAA02166
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Tue, 11 Mar 1997 14:22:03 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id OAA12006
  7.     for kermit.misc@watsun; Tue, 11 Mar 1997 14:22:02 -0500 (EST)
  8. Path: news.columbia.edu!panix!news.eecs.umich.edu!news.radio.cz!newsbastard.radio.cz!news.radio.cz!CESspool!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!howland.erols.net!agate!news.Stanford.EDU!sep!stew
  9. From: stew@sep.Stanford.EDU (Stewart Levin)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: FAST+FAST->Window slots 1 of 20
  12. Date: 11 Mar 1997 19:13:41 GMT
  13. Organization: Stanford Exploration Project
  14. Lines: 34
  15. Sender: stew@sep (Stewart Levin)
  16. Distribution: world
  17. Message-ID: <5g4at5$mte@nntp.Stanford.EDU>
  18. References: <5fb64g$5fp@nntp.Stanford.EDU> <1997Mar7.152135.95352@cc.usu.edu>
  19. NNTP-Posting-Host: oas.stanford.edu
  20. Xref: news.columbia.edu comp.protocols.kermit.misc:6736
  21.  
  22. In article <1997Mar7.152135.95352@cc.usu.edu>, jrd@cc.usu.edu (Joe Doupnik) writes:
  23. |> In article <5fb64g$5fp@nntp.Stanford.EDU>, stew@taal.Stanford.EDU (Stewart Levin) writes:
  24. |> > C-Kermit 6.0.192 on both ends (Linux and Sun OS 4.1.3)
  25. |> > Binary file transfer mode
  26. |> > FAST invoked on both ends before transfer
  27. |> > 
  28. |> > SEND'ing a large file from the Sun to the PC produces
  29. |> > 20 rapid packets followed by a much slower one-at-a-time
  30. |> > crawl and the message that I am using 1 of 20 window slots.
  31. |> > Cancelling the file takes 20 more packets to complete.
  32. |> > This happens whether or not I use the SET BUFFERS 100000 100000
  33. |> > command on both ends. Similarly with CAUTIOUS on both ends.
  34. |> > 
  35. |> > Looks like it's the Linux end that's misbehaving.
  36. |> > Have I overlooked something in the Using C-Kermit 2nd ed. chapter
  37. |> > 12?  Is there a patch I should retrieve?
  38. |> -------------
  39. |>     You are forgetting that the comms channel may not be able to
  40. |> cope. You don't say what that channel may be (or I've lost the scoop).
  41. |> Not coping leads to lost packets, and that in turn causes Kermit to
  42. |> slow down so losses are less likely. 
  43. |>     Joe D.
  44.  
  45. Following the pointers and clarifications from this newsgroup, I've
  46. had a chance to experiment.  It appears that C-Kermit is working
  47. exactly as advertised, it is just the quality of the phone connections
  48. between my home and my office are on the average not very clean.
  49. Every once in a while I do achieve a high throughput, however.  Most
  50. of the time I sustain about half the best speed.  Once again, my
  51. thanks to this group and, of course, to the authors of kermit and
  52. its user's guides.
  53.  
  54. - Stew Levin
  55.   stew@sep.stanford.edu